home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-manning-dns-nsap-01.txt < prev    next >
Encoding:
Text File  |  1993-04-06  |  18.5 KB  |  621 lines
  1.  
  2. Network Working Group                 B. Manning (Rice University)
  3. INTERNET DRAFT                            R. Colella (NIST)
  4.                                 05 Apr, 1993
  5.  
  6.  
  7.  
  8.                              DNS NSAP RRs
  9.  
  10.  
  11.  
  12. Status of This Memo
  13.  
  14.  
  15. This memo refines the approch taken in RFC 1348, updating the processing
  16. methods for encoding of NSAP addresses for the Internet community. Discussion
  17. and suggestions for improvement are requested.
  18.  
  19. This document is an Internet Draft.  Internet Drafts are working documents of
  20. the Internet Engineering Task Force (IETF), its Areas, and its Working
  21. Groups. Note that other groups may also distribute working documents as
  22. Internet Drafts).
  23.  
  24. Internet Drafts are draft documents valid for a maximum of six months.
  25. Internet Drafts may be updated, replaced, or obsoleted by other documents at
  26. any time.  It is not appropriate to use Internet Drafts as reference material
  27. or to cite them other than as a "working draft" or "work in progress."
  28.  
  29. Please check the I-D abstract listing contained in each Internet Draft
  30. directory to learn the current status of this or any other Internet Draft.
  31.  
  32. It is intended that this document will be submitted to the IESG for
  33. consideration as a standards document.    Distribution of this document is
  34. unlimited.
  35.  
  36.  
  37.                                  Abstract
  38.  
  39.  
  40.  
  41. The Internet is moving towards the deployment of an OSI lower layers
  42. infrastructure.  This infrastructure comprises the connectionless network
  43. protocol (CLNP) and supporting routing protocols. Also required as part of
  44. this infrastructure is support in the DNS for mapping between names and NSAP
  45. addresses.
  46.  
  47.  
  48. This document redefines the format of two new Resource Records for the Domain 
  49. Name System, as defined in RFC 1348. This format may be used with any OSI NSAP
  50. address format.
  51.  
  52. Expiration: 05 Oct, 1993                    [Page 1]
  53.  
  54. INTERNET-DRAFT               DNS NSAP RRs            05 Apr, 1993
  55.  
  56.  
  57.  
  58. Contents
  59.  
  60.    1   Introduction  . . . . . . . . . . . . . . . . . . . . . . . 6
  61.    2   Background  . . . . . . . . . . . . . . . . . . . . . . . . 6
  62.    3   Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
  63.    4   Structure of NSAPs  . . . . . . . . . . . . . . . . . . . . 6
  64.    5   NSAP RR specification . . . . . . . . . . . . . . . . . . . 6
  65.    5.1 The NSAP RR . . . . . . . . . . . . . . . . . . . . . . . . 6
  66.    5.2 The NSAP-PTR RR . . . . . . . . . . . . . . . . . . . . . . 6
  67.    6   DNS Operation for NSAPs . . . . . . . . . . . . . . . . . . 6
  68.    7   Examples  . . . . . . . . . . . . . . . . . . . . . . . . . 6
  69.    8   Security  Considerations  . . . . . . . . . . . . . . . . . 6
  70.    9   References  . . . . . . . . . . . . . . . . . . . . . . . . 6
  71.    10  Author's Address  . . . . . . . . . . . . . . . . . . . . . 6
  72.    A   Issues  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
  73.  
  74.  
  75.  
  76. B. Manning (Rice University)                           [Page 2]
  77.  
  78. INTERNET-DRAFT               DNS NSAP RRs            05 Apr, 1993
  79.  
  80.  
  81.  
  82. 1   Introduction
  83.  
  84.  
  85.  
  86. The Internet is moving towards the deployment of an OSI lower layers
  87. infrastructure.  This infrastructure comprises the connectionless network
  88. protocol (CLNP) [ISO8473] and supporting routing protocols. Also required as
  89. part of this infrastructure is support in the Domain Name System (DNS)
  90. [RFC1034, RFC1035] for mapping between DNS names and OSI Network Service
  91. Access Point (NSAP) addresses [ISO8348Ad2] [Note: NSAP and NSAP address are
  92. used interchangeably throughout this memo].
  93.  
  94.  
  95. This memo redefines the format of two new Resource Records (RRs) for the DNS,
  96. as defined in RFC 1348. This format may be used with any OSI NSAP format.
  97.  
  98.  
  99. This memo assumes that the reader is familiar with the DNS. Some familiarity
  100. with NSAPs is useful; see [RFC1237] or [ISO8348Ad2] for additional
  101. information.
  102.  
  103.  
  104.  
  105. 2   Background
  106.  
  107.  
  108.  
  109. The reason for defining DNS mappings for NSAPs is to support CLNP in the
  110. Internet. Debugging with CLNP ping and traceroute is becoming more difficult
  111. with only numeric NSAPs as the scale of deployment increases. Current debugging
  112. is supported by maintaining and exchanging a configuration file with name/NSAP
  113. mappings similar in function to hosts.txt.  This suffers from the lack of a
  114. central coordinator for this file and also from the perspective of scaling.
  115. The former is the most serious short-term problem. Scaling of a hosts.txt-like
  116. solution has well-known long-term scaling difficiencies.
  117.  
  118.  
  119. A second reason for this work is the proposal to use CLNP as a replacement
  120. for IP: "TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for
  121. Internet Addressing and Routing" [RFC1347]. Should this proposal be selected,
  122. the DNS must be capable of supporting CLNP addresses.
  123.  
  124.  
  125.  
  126. 3   Scope
  127.  
  128.  
  129.  
  130. The RRs defined in this paper support all known NSAP formats. In addition,
  131. the RRs support the notion of a custom-defined NSAP format. There are several
  132. ways in which an NSAP can be defined. To illustrate this feature, examples in
  133. this memo will assume that the Internet obtained an AFI from ISO and defined
  134. a fixed-field NSAP format.
  135.  
  136.  
  137. As a point of reference, there is a distinction between registration and
  138. publication of addresses. For IP addresses, the IANA is the root registration
  139. authority and the DNS a publication method.  For NSAPs, ISO8348/Ad2 is the
  140. root registration authority and the DNS is being proposed as a publication
  141. method. 
  142.  
  143.  
  144.  
  145. B. Manning (Rice University)                         [Page 3]
  146.  
  147. INTERNET-DRAFT               DNS NSAP RRs            05 Apr, 1993
  148.  
  149.  
  150.  
  151. 4   Structure of NSAPs
  152.  
  153.  
  154.  
  155. NSAPs are hierarchically structured to allow distributed administration and
  156. efficient routing. Distributed administration permits subdelegated addressing
  157. authorities to, as allowed by the delegator, further structure the portion of
  158. the NSAP space under their delegated control. Accomodation of this
  159. distributed authority requires flexibility in the DNS representation of
  160. NSAPs, allowing sub- authorities to represent the substructure they define, if
  161. any, in the DNS as well as the NSAP values themselves.
  162.  
  163.  
  164. While all NSAP structures currently known to be in use in the Internet have
  165. fixed field sizes (e.g., [RFC1237, IPTAG-92-23-PB660], some NSAP formats
  166. defined in ISO 8348Ad2 define one of the fields as variable-sized. These
  167. formats are still parsable, since the total NSAP length is known and there
  168. is, at most, one variable-sized field. These formats are accomodated in this
  169. document, even though there is no current requirement. The notation is fully
  170. described in Section 5.2, "The NSAP_PTR RR" and the processing in Section 6,
  171. "DNS Operation for NSAPs."
  172.  
  173. For the purposes of this memo, NSAPs can be thought of as a tree of
  174. identifiers.  The root of the tree is defined in Addendum 2 to ISO8348
  175. [ISO8348Ad2], and has as its immediately registered subordinates the
  176. one-octet Authority and Format Identifiers (AFIs) defined there.  The size of
  177. subsequently-defined fields depends on which branch of the tree is taken. The
  178. depth of the tree varies according to the authority responsible for defining
  179. subsequent fields.
  180.  
  181.  
  182. An example is the authority under which US GOSIP defines NSAPs [GOSIPv2FT]. 
  183. Under the AFI of 47, NIST (National Institute of Standards and Technology)
  184. obtained a value of 0005 (the AFI of 47 defines the next field as being two
  185. octets consisting of four BCD digits from the International Code Designator
  186. space [ISO6523]). NIST defined the subsequent fields in [GOSIPv2FT].The field
  187. immediately following 0005 is a format identifier for the rest of the US
  188. GOSIP NSAP structure, with a hex value of 80. Following this is the
  189. three-octet field, values for which are allocated to network operators; the
  190. registration authority for this field is delegated to GSA (General Services
  191. Administration).
  192.  
  193.  
  194. The last octet of the NSAP is the NSelector (NSel). In practice, the NSAP
  195. minus the NSel identifies the CLNP protocol machine on a given system, and
  196. the NSel identifies the CLNP user. Since there can be more than on CLNP user
  197. (meaning multiple NSel values for a given "base" NSAP), the representation of
  198. the NSAP should be CLNP-user independent. TO achive this, an NSel value of
  199. zero will be used with all NSAP values stored in the DNS. An NSAP with NSel=0
  200. identifies the network layer itself. It is left to the application retrieving
  201. the NSAP to determine the appropriate value to use in that instance of
  202. communication.
  203.  
  204.  
  205. In the event that CLNP is used to support TCP and UDP services, the NSel
  206. value used will be the appropriate IP PROTO value as registered with IANA.
  207. For "standard" OSI, the selection of NSel values is left as a matter of local
  208. administration. Administrators of systems that support support TP0-4 in
  209. addition to TCP/UDP will select NSels for use by TP0-4 that do NOT conflict
  210. with the IP PROTO vlaues.
  211.  
  212.  
  213. For the purposes of this memo, we will present NSAPs as a string of
  214. "."-separated hex values. This is common usage, not the "+" operator
  215. specified in RFC1278. The values correspond to the fields in the NSAP, as
  216. defined by the appropriate authority. For example, a printable representation
  217. of the first four fields of a US GOSIP NSAP might look like
  218.  
  219.  
  220.  
  221.                              47.0005.80.005a00
  222.  
  223.  
  224.  
  225. and a full US GOSIP NSAP is
  226.  
  227.  
  228.  
  229.                 47.0005.80.005a00.0000.1000.0020.00800a123456.01.
  230.  
  231.  
  232.  
  233. For more information on US GOSIP NSAPs, see RFC1237 [RFC1237]. Other NSAP
  234. formats have different fields and field widths; see the examples in Section 7
  235. and also [IPTAG-92-23-PB660].
  236.  
  237.  
  238.  
  239. B. Manning (Rice University)                         [Page 4]
  240.  
  241. INTERNET-DRAFT               DNS NSAP RRs            05 Apr, 1993
  242.  
  243.  
  244.  
  245. 5   NSAP RRs Specification
  246.  
  247.  
  248.  
  249. 5.1  The NSAP RR
  250.  
  251.  
  252.  
  253. The NSAP RR is defined with mnemonic NSAP and type code 22 (decimal). The
  254. NSAP RR has the following format:
  255.  
  256.  
  257.  
  258.                     < owner> < ttl> < class> NSAP < rdata>
  259.  
  260.  
  261.  
  262. All fields are required.
  263.  
  264.  
  265. The < owner> is the DNS name for the system that is addressed by the NSAP in
  266. the < rdata> field (see below).
  267.  
  268.  
  269. The meaning of the < ttl> field is as specified in RFC1034.
  270.  
  271.  
  272. The format of the NSAP RR is class insensitive.
  273.  
  274.  
  275. The < rdata> is a complete NSAP address expressed in the dotted hexidecimal
  276. notation as described in Section 7.
  277.  
  278.  
  279. NSAP RR causes no additional section processing.
  280.  
  281.  
  282.  
  283. 5.2  the NSAP-PTR RR
  284.  
  285.  
  286.  
  287. The NSAP-PTR RR is defined with mnemonic NSAP-PTR and type code 23 (decimal).
  288. It's function is analogous to the PTR record used for IP addresses [RFC1035,
  289. RFC1103], although the details of how it operates are different. The NSAP-PTR
  290. RR has the following format:
  291.  
  292.  
  293.  
  294.                   < owner> < ttl> < class> NSAP-PTR < rdata>
  295.  
  296.  
  297.  
  298. All fields are required.
  299.  
  300.  
  301. The < owner> is a complete NSAP or an NSAP prefix. The octets of the NSAP are
  302. in reverse order, with the least significant octet on the left and the AFI octet
  303. on the right. The reversal is on an octet boundary. The dotted hexidecimal
  304. notation described in Section 7 is used to separate the NSAP fields.
  305.  
  306.  
  307. The meaning of the < ttl> field is as specified in RFC1034.
  308.  
  309.  
  310.  
  311. B. Manning (Rice University)                        [Page 5]
  312.  
  313. INTERNET-DRAFT               DNS NSAP RRs            05 Apr, 1993
  314.  
  315.  
  316.  
  317. The format of the NSAP-PTR RR is class insensitive.
  318.  
  319.  
  320. The < rdata> field consists of two subfields separated by one or more spaces
  321. or tabs. The first subfield is a DNS name that corresponds to the owner of this
  322. NSAP prefix. In the case of an incomplete NSAP (i.e., an NSAP prefix), this
  323. subfield must name the root with a single ".".
  324.  
  325.  
  326. The second subfield of < rdata> contains structure information for subsequent
  327. fields of the NSAP, to the extent that they are known at this level of the NSAP
  328. tree. Strictly speaking, only the size of the next field is required to
  329. navigate the DNS NSAP tree. However, for efficiency the NSAP structure
  330. information should be included as far up towards the root as possible.
  331.  
  332.  
  333. The format of this subfield is a set of "."-separated decimal digits
  334. representing the sizes of fields subsequent to the NSAP prefix given in the
  335. < owner> field. [Should we have a BNF for this?] A trailing "." indicates
  336. that the structure information is complete. For leaf entries (i.e., when the
  337. < owner> contains a complete NSAP), this subfield must contain a single ".".
  338.  
  339.  
  340. The NSAP-PTR RR causes no additional section processing.
  341.  
  342.  
  343.  
  344. 6   DNS Operation for NSAPs
  345.  
  346.  
  347.  
  348. Name-to-NSAP mapping in the DNS using the NSAP RR operates analogously to IP
  349. address lookup. A query
  350. is generated by the resolver requesting an NSAP RR for a provided DNS name.
  351.  
  352.  
  353. NSAP-to-name mapping using the NSAP-PTR RR differs from the inverse lookup
  354. for IP addresses due to the structure of NSAPs and the requirements this places
  355. on the lookup process.
  356.  
  357.  
  358. The NSAP-to-name scheme operates with minimal a priori knowledge of how NSAPs
  359. are structured and operates according to a simple algorithm. Given an NSAP to
  360. be resolved, the only a priori information needed is that the first field of
  361. all NSAPs is one octet. The basic algorithm operates as follows:
  362.  
  363.  
  364.  
  365. 1.build an initial query to read the record associated with the first octet.
  366.  
  367.  
  368. 2.knowledge of the NSAP structure is not complete, so set (COMPL-KNOW = FALSE).
  369.  
  370.  
  371. 3.send the query.
  372.  
  373.  
  374. 4.when the response is returned, if (COMPL-KNOW == TRUE), done.
  375.  
  376.  
  377. 5.construct a more detailed query with the additional structure information from
  378.    the response.
  379.  
  380.  
  381. 6.if the structure information returned in step 4 ends with a ".", then set
  382.    (COMPL-KNOW = TRUE).
  383.  
  384.  
  385.  
  386. B. Manning (Rice University)                         [Page 6]
  387.  
  388. INTERNET-DRAFT               DNS NSAP RRs            05 Apr, 1993
  389.  
  390.  
  391.  
  392.    7.go to step 3.
  393.  
  394.  
  395.  
  396. The a priori knowledge required is that all NSAPs begin with an initial
  397. one-octet field, the AFI (Authority and Format Identifier, see [ISO8348Ad2]);
  398. this is captured in step 1.
  399.  
  400.  
  401. Steps 3 through 7 represent a simple learning algorithm in which the resolver
  402. issues queries that are increasingly detailed until the result is obtained.
  403.  
  404.  
  405. Successful termination, step 4, occures if the last query sent was based on
  406. complete NSAP structure information, as determined by the trailing ".".
  407.  
  408.  
  409.  
  410. 7   Examples
  411.  
  412.  
  413.  
  414. Three examples are presented. The first uses US GOSIP NSAPs, the second a
  415. fictitious NSAP structure based on the idea of an Internet-assigned AFI, and the
  416. third demonstrates the scheme in the presence of a variable-length NSAP
  417. field.
  418.  
  419.  
  420.  
  421. ;;;;;;
  422. ;;;;;; GOSIP-style NSAP.
  423. ;;;;;;
  424.  
  425.  
  426. <owner>                 <class>    <type>    <rdata>
  427. .                          IN        NSAP      47
  428. .                          IN        NSAP      47.0005
  429. .                          IN        NSAP      47.0005.80
  430. nist.gov                  IN        NSAP      47.0005.80.005a00
  431. emu.ncsl.nist.gov        IN        NSAP      (
  432.                   47.0005.80.005a00.0000.1000.0020.00800a123456.01)
  433.  
  434.  
  435.  
  436. 47                        IN      NSAP-PTR    .  2
  437. 0500.47                   IN      NSAP-PTR    .  1
  438. 80.0500.47                IN      NSAP-PTR    .  3.2.2.2.6.1.
  439. 005a00.80.0500.47        IN      NSAP-PTR    nist.gov  2.2.2.6.1.
  440. 01.5634120a8000.2000.0010.0000.005a00.80.0500.47
  441.                            IN      NSAP-PTR    emu.ncsl.nist.gov  .)
  442.  
  443.  
  444.  
  445. ;;;;;;
  446. ;;;;;; Internet AFI-based NSAP.
  447. ;;;;;;
  448. ;
  449.  
  450.  
  451.  
  452. B. Manning (Rice University)                         [Page 7]
  453.  
  454. INTERNET-DRAFT               DNS NSAP RRs            05 Apr, 1993
  455.  
  456.  
  457.  
  458. ; Assume XX is the Internet AFI, and XX-based NSAPs have
  459. ; a fixed 19-byte format:
  460. ;         1.1.3.3.4.6.1.
  461. ; where the numbers indicate field sizes in octets.
  462. ;
  463.  
  464.  
  465. <owner>                 <class>    <type>    <rdata>
  466. .                          IN        NSAP      XX
  467. .                          IN        NSAP      XX.12
  468. bb                        IN        NSAP      XX.12.123456
  469. reg.bb                    IN        NSAP      XX.12.123456.151617
  470. host.reg.bb               IN        NSAP      (
  471.                   XX.12.123456.151617.37383930.414243454647.89)
  472.  
  473.  
  474.  
  475. XX                        IN      NSAP-PTR    .  1.3.3.4.6.1.
  476. 12.XX                     IN      NSAP-PTR    .  3.3.4.6.1.
  477. 563412.12.XX             IN      NSAP-PTR    bb  3.4.6.1.
  478. 171615.563412.12.XX      IN      NSAP-PTR    reg.bb  4.6.1.
  479. 89.474645434241.30393837.171615.563412.12.XX  (
  480.                            IN      NSAP-PTR    host.reg.bb  .)
  481.  
  482.  
  483.  
  484. ;;;;;;
  485. ;;;;;; NSAP with variable-size field.
  486. ;;;;;;
  487. ;
  488. ; An example of an NSAP format with a variable field size.
  489. ; The example is of an X.121 NSAP.
  490. ;
  491.  
  492.  
  493.  
  494. <owner>                 <class>    <type>    <rdata>
  495. .                          IN        NSAP     37
  496. one-org.com               IN        NSAP     37.31342023011007.01
  497. two-org.com               IN        NSAP     37.575654012456.03
  498.  
  499.  
  500. 37                        IN      NSAP-PTR  com  *.1.
  501. 01.07100123203431.37     IN      NSAP-PTR  one-org.com  .
  502. 03.562401545657.37       IN      NSAP-PTR  two-org.com  .
  503.  
  504.  
  505.  
  506. B. Manning (Rice University)                         [Page 8]
  507.  
  508. INTERNET-DRAFT               DNS NSAP RRs            05 Apr, 1993
  509.  
  510.  
  511.  
  512. 8   Security
  513.  
  514.  
  515.  
  516. Security issues are not addressed in this memo.
  517.  
  518.  
  519. 9   References
  520.  
  521.    [1] ISO/IEC, "Protocol for Providing the Connectionless-mode Network
  522.        Service"
  523.        USC/Information Sciences Institute, September 1981.
  524.  
  525.    [2] Reynolds, J., J. Postel, "Assigned Numbers", RFC 1340,
  526.        USC/Information Sciences Institute, July, 1992.
  527.  
  528.    [3] Manning, B., "DNS NSAP RRS", RFC 1348, Rice University,
  529.        July, 1992
  530.  
  531.  
  532. 10  Authors' Addresses
  533.  
  534.  
  535.  
  536. Bill Manning
  537. Rice University - ONCS
  538. P.O. Box 1892
  539. 6100 South Main
  540. Houston, Texas 77251-1892
  541. USA
  542.  
  543.  
  544. Phone: +1.713.285.5415
  545. EMail: bmanning@rice.edu
  546.  
  547.  
  548.  
  549. Richard Colella
  550. National Institute of Standards and Technology
  551. Technology/B217
  552. Gaithersburg, MD 20899
  553. USA
  554.  
  555.  
  556. Phone: +1 301-975-3627 (voice); +1 301 590-0932 (fax)
  557. EMail: colella@nist.gov (Internet)
  558. /C=us/A=attmail/P=gov+nist-gw/S=colella/ (X.400)
  559.  
  560.  
  561.  
  562. A   Issues
  563.  
  564.  
  565.  
  566. A.1  User Interfaces
  567.  
  568.  
  569.  
  570. Typical user interfaces, for example nslookup, expect the inverse map string
  571. to be typed from least significant byte to most significant byte followed by
  572. IN-ADDR.ARPA. This isn't too bad for four-byte IP addresses, but can be
  573. excruciating for 20-byte NSAPs. It would be much easier if this reversal
  574. could be done by the software instead of the user. This is especially true
  575. since one convenient way to handle NSAPs is by picking and stuffing values.
  576. So, if we have an NSAP,
  577.  
  578.  
  579.  
  580.                   47000580005a0000001000002000800a12345601
  581.  
  582.  
  583.  
  584. B. Manning (Rice University)                         [Page 9]
  585.  
  586. INTERNET-DRAFT               DNS NSAP RRs            05 Apr, 1993
  587.  
  588.  
  589.  
  590. One would like to pick it, stuff it on a command line (e.g., to nslookup),
  591. and append NSAP-PTR.ARPA.:
  592.  
  593.  
  594.  
  595.       % nslookup 47000580005a0000001000002000800a12345601.NSAP-PTR.ARPA.
  596.  
  597.  
  598.  
  599. The resolver code could recognize the NSAP-PTR.ARPA domain and perform the
  600. appropriate reversal before issuing the query.
  601.  
  602.  
  603. A.4  Relationship to X.500
  604.  
  605.  
  606. It may be useful to associate an X.500 distinguished name with an NSAP. Some
  607. thought should be given to whether this is useful and how it could be done.
  608.  
  609. A.5  NSAP prefixes
  610.  
  611. Should NSAP prefixes be encoded in the DNS? This may have some useful features.
  612.  
  613. Expiration: 05 Oct., 1993                        [Page 10]
  614. B. Manning (Rice University)                        [Page 10]
  615.  
  616. -- 
  617. Regards,
  618. Bill Manning         bmanning@rice.edu        PO Box 1892
  619.  713-285-5415         713-527-6099           Houston, Texas
  620.    R.U. (o-kome)                           77251-1892
  621.